-
-
Notifications
You must be signed in to change notification settings - Fork 15
Prepare shared code: Support running on non default dns settings #893
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepare shared code: Support running on non default dns settings #893
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Partial review.
Would you mind if I added a bunch of commits to this PR to adjust a few things?
Just pushed my test fix, did not look at your changes. Dont plan on pushing more today (do a little testing) so feel free to add :) |
There is still some bits and pieces we want to change, mostly regarding the error type / error handling. This commit also moves the input fixtures for testing the resolv parser into dedicated files and utilizies rstest's #[files] attribute to generate tests based on these files. Co-authored-by: Nick Larsen <nick.larsen@stackable.tech>
Co-authored-by: Techassi <git@techassi.dev>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM otherwise
Co-authored-by: Sebastian Bernauer <sebastian.bernauer@stackable.de>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Many thanks, looks good!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some suggestions about error handling. I'm happy to make the changes if you want?
Co-authored-by: Malte Sander <malte.sander.it@gmail.com> Co-authored-by: Techassi <sascha.lautenschlaeger@stackable.tech>
Co-authored-by: Malte Sander <malte.sander.it@gmail.com> Co-authored-by: Techassi <sascha.lautenschlaeger@stackable.tech>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
let _ = KUBERNETES_CLUSTER_DOMAIN | ||
.set(retrieve_cluster_domain().context(ResolveKubernetesClusterDomainSnafu)?); | ||
create_client(field_manager).await | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this a global?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its supposed to be the new "entry point" for operators. There will be more content in there in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's basically renaming create_client
to initialize_operator
to be more expressive. By doing this we enforce that operators need to go throw this function and therefore initialize the OnceLock
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's basically renaming create_client to initialize_operator to be more expressive.
But it.. isn't? It says less about what's happening, nor does it explain why this place would be the entry point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There will be more content in there in the future.
Such as?
By doing this we enforce that operators need to go throw this function and therefore initialize the OnceLock
This still doesn't explain why it needs to be a OnceLock
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Such as?
I have branch where I warn on an unsupported Kubernetes version. It's just not merged yet because of prioritization. In the future it may also read in the recommended product version or some global config object or whatnot or check if there is an update available.
This still doesn't explain why it needs to be a OnceLock.
Agreed, I didn't try do explain that. Do you have an alternative suggestion how we can make this easy-to-use in operators? It looks very intuitive to me, but I'm not a Rust expert!
In the beginning we had a LazyLock, but @Techassi mentioned that we would panic on e.g. an invalid DomainName being configured, and that the operators should error instead of panic, so we needed to change to a OnceLock.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have branch where I warn on an unsupported Kubernetes version.
That still sounds like a part of.. creating a k8s client.
Agreed, I didn't try do explain that. Do you have an alternative suggestion how we can make this easy-to-use in operators? It looks very intuitive to me, but I'm not a Rust expert!
I would have said you could store it in the Client
, but on second thought maybe it would make more sense to create a separate KubernetesClusterConfig
struct.
LazyLock
/OnceLock
is for caching expensive static values that can't be const
for whatever reason (like a precomputed HashMap
), not for configuration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We replaced the LacyLock with a KubernetesClusterInfo struct in #896
|
||
match env::var(KUBERNETES_SERVICE_HOST_ENV) { | ||
Ok(_) => { | ||
let cluster_domain = retrieve_cluster_domain_from_resolv_conf(RESOLVE_CONF_FILE_PATH)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're going to do this hack (and I still don't think we should), can we please at least punt that until vNext instead of sneaking it in just before the release?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have many customers that require this, i think there is no way to punt on this for now, but calls for intensive testing for sure!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can punt on autodetection while still keeping the override.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We removed auto-detection in #896 again
Description
Part of stackabletech/issues#436.
Definition of Done Checklist